Location based services (LBS) is an emerging class of services that are provided based on the location(s) of wireless transmit/receive units (WTRUs) and their users. Various wireless communication standards, such as third generation partnership project (3GPP) and 3GPP2, define the network architectures supporting LBS at the application and service architecture level. Other groups, such as the open mobile alliance (OMA) location technical specification group, also define the service level architectures for LBS.
FIG. 1 illustrates the relation of location services (LCS) clients and servers in the core network with the GSM EDGE radio access network (GERAN) 120 and universal terrestrial radio access network (UTRAN) 130 access networks. The core network includes a gateway mobile location center (GMLC), (a requested GMLC (R-GMLC) 142, home GMLC (H-GMLC) 144, visited GMLC (V-GMLC) 146), a privacy profile register (PPR) 148, and other network nodes.
An LCS server is a network-based entity that serves location information to an LCS client and enforces access control and security policies in terms of location services. In the 3GPP centric architecture of FIG. 1, the various GMLC's correspond to the location services as defined above. As part of the service or operation, an LCS client, either one that resides inside, attached to, or embedded within a WTRU 110 (an internal LCS client 115), or one that resides external to the WTRU 110 (an external LCS client 150), may request the location information of the WTRU 110 to an LCS server, (i.e., GMLC). There may be more than one internal LCS client 115, more than one external LCS client 150 and more than one LCS server. A GMLC 142, 144, 146 contains functionality required to support LCS. In one public land mobile network (PLMN), there may be more than one GMLC. A GMLC is the first node an internal LCS client 115 or an external LCS client 150 accesses in a PLMN.
After performing registration authorization, the GMLC sends positioning requests to either mobile switching center (MSC), serving GPRS support node (SGSN) or MSC server, and receives final location estimates from the corresponding entity. Information needed for authorization, location service requests and location information may be communicated between GMLCs, located in the same or different PLMNs. The RGMLC 142 is the GMLC which receives the request from an LCS client. The HGMLC 144 is the GMLC residing in the target WTRU's home PLMN, which is responsible for the control of privacy checking of the target WTRU. The VGMLC 146 is the GMLC which is associated with the serving node of the target WTRU.
The PPR 148 stores privacy information of the WTRU 110. The PPR 148 executes privacy checks and sends the privacy check results to other network nodes. The PPR 148 is considered as an entity that is separate from, but supportive of, a ‘location server’ that is defined above, in that the PPR 148 provides the privacy (and access control or policy-related) information about the WTRUs for whom location services are sought.
Conventional methods of authentication and access control to a wireless network and/or applications and data on a WTRU and network servers have relied on techniques such as user authentication by single or multi-factor evidence, cryptographic message encryption and decryption, rule and behavior-based access control to network resources and/or device applications, and trust processing techniques that verify the applications and operating system's code integrity. Conventional methods have not considered the concepts and use of physical (geographical) and logical location information as a decision variable for access control and authentication.
Newer WTRUs have location and positioning capabilities as provided by technologies, such as a global positioning system (GPS), assisted GPS (A-GPS), or a wide area augmentation system (WAAS)). Various industry organizations, such as the 3GPP and GSM association (GSMA), have considered the use of LBS and specified requirements for such services. However, the prior art work have limited its focus on providing services that can be summarized as navigation systems, finding and tracking users, (e.g., tracking of fleets or children), objects, (e.g., nearest stores or restaurants), or resources, (e.g., phone service centers or nearest WiFi hot-spots). In other words, the location information has been used as a factor of service-enablers but not as service limiters or service controllers. Accordingly, the prior art has not considered the usage of location information as a decision variable in access control and authentication.
In addition, in prior art, the location information is limited to the physical location of a WTRU. The prior art has not considered a more expanded definition of location information, such as proximity, enclosure, exclusion, referencing to trusted locations of known objects or entities.
Further, conventional methods have not considered how location-related components and information can be tied to the architectures of network services, devices, content and applications in a trusted manner. For example, location-reporting software for a GPS device attached to a WTRU may be compromised and may furnish false information about the physical location of the WTRU to a service provider. The service provider may then be spoofed to allow specific services that the WTRU should not have been allowed to have an access to if the WTRU had reported real, uncompromised location. Securing the measuring, reporting, storing, and processing of location information needs careful consideration.
Further, conventional methods have not sufficiently considered the use of location information in various mobile application processing, including digital rights management (DRM) and mobile payment, or the like, despite the fact that the location of the mobile device which wishes to conduct certain processing for network-based service application could become a valuable source of information that can be used to authenticate and securitize the application processing, if such information can be trusted and securely handled. For example, in conventional mobile DRM application protocols, (such as the OMA DRM 2.0 protocol), the use of secure location information as part of the device profile information or as part of the rights objects acquisition protocol (ROAP), has not been considered.